The Session Initiation Protocol (SIP) is an Internet Engineering Task Force (IETF) standard protocol for initiating an interactive user session that may involve multimedia elements such as video, voice, chat, gaming, and virtual reality. Like the Hypertext Transfer Protocol (HTTP) or the Simple Mail Transfer Protocol (SMTP), SIP works in the application layer of the Open Systems Interconnection (OSI) communications model and can establish multimedia sessions or Internet telephony calls, modify, and terminate them. SIP can also be used to invite participants to unicast or multicast sessions that do not necessarily involve the initiator. Because SIP supports name mapping and redirecting services, it makes it possible for users to initiate and receive communications and services from various locations, and for networks to identify the users wherever they are. SIP is a request-response protocol, dealing with requests from clients and responses from servers. Participants are identified by SIP Uniform Resource Locators (URLs). SIP Requests can be sent through any transport protocol, such as for example the User Datagram Protocol (UDP), the Stream Control Transmission Protocol (SCTP), or the Transport Control Protocol (TCP). SIP determines the end system to be used for the session, the communication media and media parameters, and the called party's desire to engage in the communication. Once these are assured, SIP establishes call parameters at either end of the communication, and handles the call transfer and termination. SIP is specified in IETF's Request for Comments (RFC) 3261, which is herein included by reference in its entirety.
SIP has emerged as the protocol of choice for handling session setup in the IP Multimedia Subsystem (IMS).
Being employed for most session setup scenarios in IMS, it has been noticed that SIP is characterized by large message sizes, which results in increased processing demands on the nodes (e.g. terminals and servers) involved in the SIP sessions. For example, typical SIP messages range from a few hundred bytes up to a few thousand bytes (in certain occasions). With the planned usage of SIP protocol in wireless handsets, as part of 2.5G and 3G cellular networks, where over-the-air bandwidth is scarce and call set-up time is critical, large message size becomes a problem.
A partial solution to this drawback was provided by the use of SigComp (Signalling Compression). RFCs 3320 and 3321, which are also included herein in their entirety, specify a protocol on the IETF standards track that may be used to compress text-based application layer protocols such as SIP. SigComp enables compression and decompression of messages sent across networks, which may have stringent bandwidth restrictions. SigComp may interface with the three main transport layer protocols, namely TCP (Transport Control Protocol), UDP and SCTP. One of the main drivers for the development of SigComp is precisely its planned usage of text-based protocols like SIP in wireless handsets as part of 2.5G and 3G cellular networks. In such networks, the large SIP message size coupled with relatively low data rates across the radio interface results in significant transmission delays. SigComp provides a means to reduce this problem by offering robust, lossless compression of application messages. In SIP, SigComp is invoked and negotiated between the parties involved in the session (e.g. terminals and/or servers). A client may initiate the compression mechanism by requesting the use of SigComp through the inclusion of the extension header “comp=sigcomp” in the request message. SigComp implements a decompression virtual machine, which allows applications to dynamically select the compression algorithm of their choice. Thus, SigComp allows two peers to perform compression/decompression using any compression technique, provided that the decompressor is provided with the byte code (logic) needed to perform the decompression to recover the original message. This flexibility is achieved by virtue of the fact that the byte code for carrying on the decompression is transferred within the SigComp messages, hence allowing the originating party to practically choose any compression algorithm it sees fit, without causing any inter-working problems.
Upon establishment of a session with SigComp, a node (e.g. a terminal) sends a first message along with the byte code, which is binary program; this program indicates to the receiving terminal how it can decompress the compressed message using a SIP dictionary. The IETF's RFC 3485, also included herein in its entirety, specifies a standard SIP dictionary. When sending a message, the SIP message content is compared with the SIP dictionary. If a match is found between a text string of the message and one of the dictionary, the message as sent does not include that string, but instead comprises a start address where, in the dictionary, the receiver can find the missing text string. The length of the string is also included so that the receiver terminal can recompose the compressed message using its own identical copy of the dictionary.
Reference is now made to FIG. 1 (Prior Art), which is high level representation of a SIP static dictionary 100. Such a static dictionary stores string (text) expressions E1-En 102i typically used in SIP messages. In many implementations, the text string content of the SIP dictionary 100 is not separated into individual expressions as such, with defined limits or borders, but is rather a contiguous text string, e.g. of the type E1E2E3 . . . En, which comprises of different contiguous text expressions. Some or all of these expressions Ei 102i or parts of the contiguous text string may include complete SIP messages as well. They are used for replacing strings which are part of transmitted SIP messages, or SIP messages in their entirety, thus reducing the size of the transmitted message (compressing the message). Typically, the size and number of expressions Ei is limited by the size of the memory allocated to the dictionary in a given node, particularly when such a node is a mobile terminal. The SIP dictionary 100 is said to be static because its content is provided before, or at the beginning of a given SIP session, and is not further altered during said session.
Reference is now made to FIG. 2 (Prior Art), which is a high level representation of a dictionary index 200. When an expression of a given SIP message is detected to match an expression Ei of the dictionary, that expression of the SIP message is replaced by the dictionary index 200 pointing to the expression found within the dictionary. As the index size is much smaller than the replaced expression, the size of the transmitted message is reduced, thus compressing the message. The index 200 may comprise the location 202 of the expression in the dictionary 100, and the expression length 204, thus providing sufficient information to the receiver side to retrieve the expression from its own identical copy of the dictionary 100, so that the receiver can reconstruct the original message (decompression).
Reference is now further made to FIG. 3 (Prior Art), which is a high level nodal operation and signal flow diagram of a SigComp compression/decompression scheme using a SIP static dictionary 100. Shown in FIG. 3 is a sender 302 (e.g. a terminal or a server) and a receiver 304 (e.g. another terminal or server), each one having a SigComp module 306 and 308 respectively and copies of the same static SIP dictionary 100. When the sender 302 sends a compressed message to the receiver 304 using SigComp for the first time, it compresses the message using its static dictionary 100, action 305. Part of action 305, the SigComp module takes expressions Ei from the dictionary 100, and using these expressions, attempts to match parts of the message that is be compressed. The matched parts of the message are replaced within the message with the dictionary index of the dictionary's matching expressions. In many implementations, the individual expressions Ei of the dictionary are data bytes, so that the comparisons between the expressions Ei and the message parts are performed byte by byte. Then, the sender 302 sends the compressed message 310 via its SigComp module 306, the message including the index 309 required for decompression along with the byte code 311 to be used also for decompression by the receiver 304. The later, upon receipt of the compressed message 310, stores the byte code, action 312, and then uses the byte code along with the index 309 for decompressing the message 310, i.e. for retrieving from its own static dictionary 100 the missing expressions of the message, thus reconstituting the original message. The receiver 304 then confirms the safe receipt of message 310 via a message confirm action 314. Upon receipt of message 314, the sender 302 implicitly deducts that the byte code 311 was successfully received by receiver 304. Then the sender 302 may send compressed messages as described without again sending the byte code 311, but rather only including the new index required for decompression of subsequent messages. For example, the sender 302 may compress a second message 316, and transmit the compressed message 316, to the receiver 304, using its SigComp module 306. For this purpose, the sender's SigComp module 306 uses the dictionary 100 to again replace any expressions of the message 316 found to match expressions from the dictionary 100 with corresponding expression indexes 309′ as described hereinbefore, action 315. The message 316 is then sent to the receiver 304 which, upon receipt of the compressed message, uses again its own SigComp module 308 to decompress the message, action 318, by retrieving from its own copy of the dictionary 100 the expressions that correspond to the indexes 309′ contained in the message 316, thus reconstructing the original message.
Due to the heavy signaling involved in SIP, 3GPP (the 3rd Generation Partnership Project) IMS Release 5 standards mandates SigComp (Signaling Compression) as the compression/decompression protocol of choice for IMS. SIGCOMP stacks can be used in 3G user terminals and all types of Call State Control Functions (CSCFs.)
The major components of SigComp are:                Compressor is the component that compresses the messages and uploads the byte code for the corresponding decompression algorithm to the decompressor as part of the SigComp message.        Decompressor (also called Universal Decompressor Virtual Machine, UDVM) provides a mechanism to uncompress messages by interpreting the corresponding byte code. The UDVM can be used to decompress the output of various compressors such as DEFLATE (defined in the IETF's RFC-1951).        State Handler retains information between received SigComp messages and thus, eliminates the need to send decompression instructions with each of the compressed message.        
SigComp is agnostic of compression algorithms, supports state handling for better compression ratio, is pluggable with any protocol stack and provides APIs (Application programming Interface) for easy integration with any application.
Besides static SIP dictionary defined in the IETF's RFC 3485, SigComp can also use dynamic SIP dictionaries, which instead of being pre-defined as the static SIP dictionaries, they are rather updated during an ongoing session each time a message is successfully decompressed. In such instances, the entire decompressed SIP message is copied in the dynamic dictionary in a round-robin manner, i.e. replacing the oldest message of the dictionary. In this manner, most recent decompressed messages are kept in the dictionary to serve as a basis for subsequent compression/decompressions.
However, it has been proven through field trials that the current SigComp specifications have several shortcomings, which result in compression ratios that are significantly less that what has been anticipated. For example, for some time sensitive application services such as Push-To-Talk (PTT), the latencies resulting from the poor ratios achieved for message compression were unacceptable.
Hypothesis to explain the reasons why the current SigComp specifications are not optimal are as follows:
Dynamic compression does not always work with non-reliable transport medium. This is due to the limited memory storage in end-user devices and the limitations of this memory (size of memory) by the SigComp specification for storing entire SIP messages. In many devices, it is impossible to simultaneously store more than 2 entire SIP message. Since SIP messages can get out of order because of the use of UDP, decompression failure occurs, as the state against which decompression should be performed for a disordered (out-of-sequence) message had to be released due to shortage of memory. Eliminating this problem in its entirety is costly, both in terms of performance and efficiency. The root problem is that the dynamic compression is based on stateful compression, which does not work well with non-reliable transports in combination with limited terminal memory for storing SIP messages. This situation thus leads to messages that are required for the decompression to be prematurely released, due to memory limitations. Therefore, data against which compression/decompression is taking place is constantly overwritten in a round robin fashion. While the overwriting was deemed useful in improving compression according to the SigComp specification, the assumption that by using current traffic information to compress future message would yield a better performance proved to be faulty, as it misses some key facts: the above is true only for a monolithic protocol, which is not the case for SIP, which includes various extensions for a variety of SIP-based services that are unrelated to the establishment of multimedia sessions, such as for example the presence service. Thus, in SIP, the current traffic is rarely an indication of the future traffic.
Conclusively, there is no predictability when it comes to compression performance, when dynamic compression (based on the IETF's RFCs 3485, 3220, or 3321) is used with SigComp, since it very much depends on the traffic type, and such compression performance cannot be optimized for a live applications such as PTT, where latency to set up the session is the key performance indicator.
Although a thorough search has revealed no relevant prior art for the present invention, the international publication WO 2005/011175 bears some relation with the field of the present invention. This publication teaches a system and method for compressing and compressing SIP messages using a tokenized binary protocol. Tokens represent message elements of internal data structures defining SIP messages. Such tokens may be assigned to message elements based on various design requirements. According to this publication, various kinds of dictionaries may be used such as for example static dictionaries which are never transmitted, or dynamic message dictionaries containing strings found only in specific messages. Furthermore, local dictionaries may contain additional text strings which are specific to a particular domain, or to a particular device. However, the international publication WO 2005/011175 stops short of suggesting creation of dictionaries as the one described in the present invention.
The US patent application publication US2003/0233478 also bears some relation with the field of the present invention. This publication teaches a protocol message compression scheme for wireless communications system, wherein text messages are compressed for transmission. The method includes parsing text strings and encoding numerical values with a binary representation, analyzing the values of the text strings and populating a session specific codebook, which is initialized to empty, with partial strings from the values. This process is achieved as messages are processed for transmission, during real traffic. The method of compressing the message for transmission may also include parsing the message with a template and generating at least one substrings to be transmitted; parsing the at least one substring with entries in a session specific codebook and generating the first part of the compressed message; populating the session specific codebook with entries from unknown field values; parsing any unmatched substring with entries from a first static dictionary and generating a second part of the compressed message; parsing any still unmatched substring with entries from a second static dictionary and generating the third part; and combining the first part, the second part, and the third part of the compressed message for transmission. Nevertheless, the US patent application publication US2003/0233478 also stops short of suggesting the creation of dictionaries as the one described in the present invention.